Methods, networks and nodes for dynamically establishing encrypted communications

ABSTRACT

Methods, networks and nodes for dynamically establishing encrypted communications between a first node having a first identification and a first private key and a second node having a second identification and a second private key. A first signal comprising information indicative of the first identification of the first node is transmitted, then, upon receipt of the first signal by the second node, a second signal comprising information indicative of the second identification of the second node and a first portion of a symmetric key is transmitted, then, upon receipt of the second signal by the first node, a third signal comprising a second portion of the symmetric key is transmitted.

FIELD

This disclosure relates to methods, networks and nodes for establishingcommunication between nodes and, more particularly, to such methods,networks and nodes dynamically establishing encrypted communicationsbetween nodes.

BACKGROUND

Communication networks are well known in the art. Multiple nodes may beincorporated into a common communication system for the purposes ofexchanging data of various kinds. Such networks may exist for myriadpurposes and incorporate anywhere from two nodes to millions of nodes.While many such networks are relatively static in location andcomposition, networks are increasingly physically mobile and rapidlyvariable in composition. Thus, while many conventionally wired networksdo not pose substantial challenges in maintaining the integrity of thenetwork even when nodes move about and enter and leave the network,managing mobile networks while also maintaining the security of thenetwork may create relatively greater challenges in supporting thenetwork.

Contemporary standard networking protocols, such as Open Shortest PathFirst (OSPF) and Border Gateway Protocol (BGP), were originally designedfor largely static, terrestrial networks. As such, they incorporateconventional security mechanisms to combat conventional static,terrestrial network security problems. Such security mechanisms tend torely on static information, reliable fast network connections, and, invarious cases, a reliable connection to a key management server. In suchnetworking protocols, network administrators may manually configure thesecurity for each router link, which may be time consuming, complicatedand not practical for a mobile network. Certain security protocols mayutilize signed certificates for message authentication, which again maybe impractical in circumstances where connections are not as fast,reliable or provide as much or sufficient bandwidth as terrestrialnetworks.

Such problems may be magnified in the event the network in question isan airborne network or otherwise non-terrestrial. In such networks, therelative speed of each node may cause the composition of the network andlinks between nodes to change with relatively high frequency. While OSPFand BGP may function to operate such a non-terrestrial network, securitywith such protocols in an environment with fast-changing networkmembership and links may be unacceptably easy to compromise or otherwisevulnerable. In such a non-terrestrial network, sub-networks, andparticularly those on the spatial fringe of the network, may have one ormore attributes that hamper the operation of existing routing securitysystems, including bandwidth constrained wireless links, mobile ad hocnetwork operation, and intermittent connectivity with the globalinformation grid (GIG) backbone network.

Various specific types of routing protocols such as OSPF and BGP, suchas digital signature based OSPF, S-BGP, and soBGP, employ digitalcertificates for message authentication and rely on a public keyinfrastructure for encryption key management, such as key updates andkey revocation. The bulkiness of digital certificates may make such anapproach impractical for the bandwidth-constrained wireless subnets of anon-terrestrial network. Furthermore, intermittent disconnections of anon-terrestrial subnet from a backbone of the network of the globalinformation grid may make the certificate servers temporarily orpermanently inaccessible, thereby hindering the operation of the keymanagement mechanism. Finally, access to the Public Key Infrastructure(PKI) services by the routing system typically assumes correctfunctioning of the routing function to route packets to and from thenetwork PKI servers.

SUMMARY

A network with a networking protocol has been developed which mayimprove network connectivity and reduce communications outages relativeto conventional networking protocols in networks with mobile nodes. Invarious embodiments, the network protocol incorporates functionalitysuch as dynamic discovery mechanism to automatically and with relativelyquick response time discover and incorporate new nodes into the network.The network protocol may further incorporate proactive link monitoringbetween nodes to regularly and rapidly assess the state of the networklinks. In additional embodiments, the protocol may further incorporate amobility index of nodes within the network to provide the network anability to anticipate movement of nodes within and outside of thenetwork and plan interaction within the network accordingly.

As a consequence of these features, a network having mobile nodes may beactively managed so as to provide networking capabilities on local,direct communication links. By providing for dynamic discovery, nodesmay enter the network rapidly. By monitoring links, broken links mayresult in a rerouting of the network and the deletion of absent nodes.By providing a mobility index, links within the network may beestablished in a manner that is mindful of a likelihood of a link to bepresent in the future.

In so doing, military applications in particular may be strengthenedrelative to existing networks. In various mobile military networks, theadvantages of networking may be maintained while keeping links directand relatively secure. In a highly mobile environment, nodes may enterand leave the network with relative seamlessness and minimal disruption,either to the node's operation or the operation of the network ingeneral. Such benefits may be felt particularly in aerial networks,where fast-moving military aircraft maneuvering aggressively may placeunique stress on network management.

In an embodiment, a method dynamically establishes encryptedcommunications between a first node having a first identification and afirst private key and a second node having a second identification and asecond private key. A first signal comprising information indicative ofthe first identification of the first node is transmitted, then, uponreceipt of the first signal by the second node, a second signalcomprising information indicative of the second identification of thesecond node and a first portion of a symmetric key is transmitted, then,upon receipt of the second signal by the first node, a third signalcomprising a second portion of the symmetric key is transmitted.

In an embodiment, at least one of the second signal and the third signalis encrypted.

In an embodiment, the at least one of the second signal and the thirdsignal are encrypted according to at least one of the first portion ofthe symmetric key and the second portion of second symmetric key.

In an embodiment, the first private key and the second private key arebased, at least in part, on time.

In an embodiment, the first portion of the symmetric key is generatedwith the second node, after the transmitting the first signal step,based, at least in part, on the information indicative of the firstidentification of the first node and the second private key, and thesecond portion of the symmetric key is generated with the first node,after the transmitting the second signal step, based, at least in part,on the information indicative of the second identification of the secondnode and the first private key.

In an embodiment, the first node comprises a first processor and thesecond node comprises a second processor, the first processor and thesecond processor are trusted hardware, and the generating with thesecond node step is software implemented on the second processor and thegenerating with the first node step is software implemented with thesecond processor.

In an embodiment, the first processor and the second processor implementa software scheme having a plurality of software layers, and wherein thegenerating with the second node step and the generating with the firstnode steps are software implemented as one of the plurality of softwarelayers.

In an embodiment, the first node comprises a first processor and thesecond node comprises a second processor, at least one of the firstprocessor and the second processor is untrusted hardware and, if thefirst processor is untrusted, the generating with the first node step isperformed with a first hardware module coupled to the first node andotherwise the generating with the first node step is performed with thefirst processor, and, if the second processor is untrusted, thegenerating with the second node step is performed with a second hardwaremodule coupled to the second node and otherwise the generating with thesecond node step is performed with the second processor.

In an embodiment, each of the transmitting steps transmits only one datapacket apiece.

In an embodiment, at least one of the first identification and thesecond identification is an internet protocol address of the first nodeand an internet protocol address of the second node, respectively.

In an embodiment, at least the transmitting the first signal step is amulticast signal to at least the second node and a third node differentthan the first node and the second node.

In an embodiment, the first step is returned to upon completion of thetransmitting the third signal.

In an embodiment, the step of returning to the transmitting the firstsignal step refreshes the symmetric key.

In an embodiment, the step of returning to the transmitting the firstsignal step occurs periodically.

In an embodiment, the symmetric key has an expiration time and whereinthe returning step occurs after the expiration time.

In an embodiment, the first private key is the same as the secondprivate key.

In an embodiment, the first private key is different than the secondprivate key.

In an embodiment, dynamically configured encrypted network has a firstnode having a first identification and a first private key and a secondnode communicatively coupled to the first node and having a secondidentification and a second private key. The first node is configured totransmit a first signal comprising information indicative of the firstidentification of the first node, the second node is configured totransmit, upon receipt of the first signal by the second node, a secondsignal comprising information indicative of the second identification ofthe second node and a first portion of a symmetric key and the firstnode is configured to transmit, upon receipt of the second signal, athird signal comprising a second portion of the symmetric key.

In an embodiment, a node configured to dynamically establish encryptedcommunication with a second node having a second identification and asecond private key has a first identification different from the secondidentification and a first private key different from the second privatekey and a transceiver. The transceiver is configured to transmit a firstsignal comprising information indicative of the first identification ofthe first node, receive a second signal, transmitted by the second nodeupon receipt of the first signal, comprising information indicative ofthe second identification of the second node and a first portion of asymmetric key and transmit, upon receipt of the second signal, a thirdsignal comprising a second portion of the symmetric key.

FIGURES

FIG. 1 is a block diagram of a network;

FIG. 2 is a network stack for the network of FIG. 1;

FIG. 3 is an application provider interface for router hardware;

FIG. 4 is a closed-system hardware implementation of a organicallyassured routing system; and

FIG. 5 is a flowchart for creating an organically assured network.

DESCRIPTION

FIG. 1 is an exemplary mobile network 10. In various embodiments,network 10 is airborne or otherwise non-terrestrial. Individual nodes 12of network 10 represent in various embodiments vehicles such as aircraftor space vehicles equipped with networking equipment. In certainembodiments, a single vehicle may incorporate multiple nodes 12. In suchembodiments, the nodes 12 of a single vehicle may act independentlywithin the scope of network 10, or may be joined to functionally performas a single node. Such nodes 12 are equipped with conventionalnetworking equipment as is well known in the art and which may bedeveloped in the future, including wireless networking equipment totransmit and receive networking communications.

Owing to the mobile nature of network 10, nodes 14 not already a part ofnetwork 10 may joint network 10 as appropriate. In addition, certainnodes 12 may leave network 10. The reasons for nodes 12, 14 entering andleaving network 10 may be functional, i.e., the nodes' 12, 14 presencein network 10 is or is no longer needed or desired. In variousembodiment, however, the entry or exit of nodes 12, 14 in network 10 mayowe to geo-spatial reasons, i.e., node 12, 14 is or is not withineffective range of the network, either because effective networkcommunication is impossible or impractical due to range, or because node12, 14, while being physically capable of communicating with network 10,is inside or outside of a range at which effective coordination withother nodes 12 of network 10 becomes impractical.

As illustrated, nodes 12, 14 have vectors 16 representing a speed anddirection of motion of node 12, 14. Thus, while certain nodes 12 havevectors 16 representing similar speeds and directions of movement, andthus will tend to maintain relative position with respect to oneanother, other nodes 12, 14 have vectors 16 representing speeds anddirections of movement which are contrary to vectors 16 of other nodes12, and thus will tend to change their position relative to other nodes12.

As indicated above, nodes 12 incorporate conventional networkinghardware as known in the art or which may be developed in the future.Nodes 12 variably also incorporate computer processing hardware andsoftware 18 for general node management as well as for conductingnetworking operations. In various embodiments, certain nodes 12 haveprocessor 18 while others do not, though in various embodiments at leastsome nodes 12 in network 10 incorporate processor 18.

As illustrated, various nodes 12 are configured with a communicationlink 19 to other nodes 12 of network 10. In various embodiments, some orall of nodes 12 incorporate links 19 to each other node 12 in network10. However, particularly in embodiments where links 19 are ofrelatively limited spatial scope and nodes 12 are relatively spreadapart, not all nodes 12 may have a link 19 to each other node 12. Insuch embodiments, nodes 12 may nevertheless communicate with other nodes12 of network 10 even without a direct link 19 by conducting multi-hopcommunications as well known in the art or which may be developed in thefuture.

In various embodiments, processor 18 incorporates software configuredfor routers running on trusted systems. In various applications,particularly those where the network administration has an ability tocontrol the specifications of node 12 hardware, such as processor 18,and user access to such hardware, the hardware may be deemed trusted andthus of particular ongoing network access reliability.

In an embodiment, software for processor 18 includes a key distributionserver, a key negotiation protocol and a device driver (20, FIG. 2,below). The key distribution server may be software that operates on oneprocessor 18 for the benefit of multiple nodes 12 though not necessarilyall nodes 12 of network 10. Key distribution may be centralized. Ingeneral, such pre-loading private encryption keys is conventional andwell known in the art such as by loading such private encryption keysinto each node 12 either wirelessly or by physical connection. It isnoted that in certain circumstances it may be impractical or impossibleto update encryption keys for network 10 after beginning operation ofnetwork 10, such as when aircraft of network 10 takes off or otherwisebecomes separate from their ground support systems.

In an embodiment, a key negotiation protocol periodically sends outmulticast messages searching for neighboring nodes 12. In an ad hocnetwork environment where the layout of network 10 is dynamic, nodes 12may regularly or irregularly converge and/or diverge. The keynegotiation protocol may operate to detect when two nodes 12 are withincommunication range of one another. The key negotiation protocol maythen used by neighboring nodes 12 to set-up and maintain a securityassociation during connection. The neighboring nodes 12 may beconfigured to authenticate each other and verify that nodes 12 areallowed to communicate with one another. The key negotiation protocolmay then be used build an encryption tunnel or other communicationscheme well known in the art or to be developed in the future throughwhich the routing protocol messages are sent.

In various embodiments, identity-based encryption (IBE) may be utilizedto authenticate nodes 12 and set-up symmetric communication that may beused to encrypt and sign routing messages. In an embodiment, the keynegotiation protocol uses identity-based encryption to authenticatenodes 12 and to negotiate a symmetric key for use in furthercommunication in an encrypted tunnel or other communication scheme knownin the art. Identity-based encryption may utilize reduced bandwidthoverhead in comparison to other communication schemes typically used inthe art to share public keys, though various circumstances may makealternative schemes as is well known in the art or which may bedeveloped in the future more viable. In various embodiments, pre-storedpublic keys may not be necessary. Periodically, neighboring nodes 12 mayuse a key exchange protocol to negotiate a new symmetric key for anexisting encrypted tunnel in order to increase the difficulty for anoutside attacker to break the encryption scheme.

The software may include or may consist entirely as a device driver (32,FIG. 2, below) residing on processor 18. In certain embodiments, thedevice driver resides in kernel 24 of the operating system of processor18. In such embodiments, kernel 24 may be added to the operating systemas a module that is loaded when the operating system starts up.

In an embodiment, processor 18 is trusted hardware. For purposes herein,trusted hardware means hardware that is manufactured and/or certifiedand/or verified to be operable under the methods described herein orwhich may otherwise be trusted to follow network rules as describedherein. In an embodiment, trusted hardware meets the Trusted ComputerSystem Evaluation Criteria, DoD 5200.28-STD, Dec. 26, 1985, also knownin the art as the “Orange Book”, promulgated by the United StatesDepartment of Defense. Additional governmental or commercial standardsmay be utilized in lieu of or in addition to the Orange Book, as well asversions of the Orange Book and other standards which have beenpromulgated in the past and which may be developed in the future. Suchmanufacture, certification and/or verification may be accomplished, forexample, by a manufacturer, assembler, configurer and/or controller ofthe network operating in accordance with features and/or techniquesdescribed herein. This typically means that such trusted hardware iseither (1) manufactured or configured to operate in accordance withfeatures and/or techniques described herein, and not subsequentlymodified in a way which would compromise the security set forth herein;or (2) verified to operate in accordance with features and/or techniquesdescribed herein, e.g., verified by an independent trusted verifier orverification group, such Verisign for example. In an embodiment, (1)manufacture of trusted hardware is controlled to operate withinpredetermined standards, particularly, predetermined security standards;plus (2) such manufactured trusted hardware would be rendered either (a)inoperable if modified in such a way as to defeat such predeterminedstandards, or (b) any modifications which would defeat suchpredetermined standards would be known or could be determined by networkor its operator, controller or user. In case of such a modification,such hardware would be classified or reclassified as untrusted hardware.

Trusted hardware may be made to particular specifications of amanufacturer, configurer, controller and/or user of network 10 and bemade either by the manufacturer, assembler, configurer, controllerand/or user of network 10 or a contract manufacturer which is itselfconsidered trustworthy by the manufacturer, assembler, configurer,controller and/or user and, thus, can be certified to be trustworthy.Hardware that is untrusted, by contrast means hardware that does nothave or cannot obtain such certification and/or verification and which,under certain circumstances, may have been manufactured or may have beenmodified to defeat certain protection or protections of the methods,networks and nodes described herein. Such untrusted hardware may includecommercially available, off-the-shelf hardware or hardware otherwiseprovided to the user of network 10 by a source or manufacturer notconsidered or otherwise certified as being reliable.

In various embodiments, the device driver is configured to interceptpackets between network 10 and routing software 28 on processor 18. Incertain embodiments, the device driver manages all network communicationbetween nodes 12 of network 10. In so doing, the device driver mayprotect route protocol messages regardless of what routing software isused. The device driver may be invisible to the routing software,thereby allowing network 10 to maintain a secure environment withoutrespect to the routing software used and without need for nodes 12 tomodify or change the routing software used by such nodes 12.

In various embodiments, network 10 incorporates router security module19. Router security module 19 may be utilized where processor 18 is nottrusted hardware and may be unnecessary when processor 18 is trustedhardware. As illustrated, router security module 19 is a separatehardware component. In an embodiment, the router security module may besoftware configured to operate on untrusted processor 18 or otheruntrusted hardware configured to run software, such as other processors,microcontrollers and the like which may be components of node 12.Alternatively, the router security module can be integrated with therouter software though an application provider interface (API) or may berun on an external, conventional processor 18 that is connected to thenetwork 10 through an interface such as conventional wireless linksutilized between nodes 12 of network 10.

Routing protocol implementations such as Open Shortest Path First (OSPF)and Border Gateway Protocol (BGP) may be incorporated in router securitymodule 19. In various embodiments, router security module 19 may beconfigured to provide multiple levels of protection for network 10. Inan embodiment, a first level of protection is a route protocol monitorto seek to protect network 10 from false routing messages. A secondlevel may be provided when a network administrator is concerned aboutnode 12 exfiltration and the compromise of a routing database.

In an embodiment, router security module 19 protects network 10 byrunning implementations of the routing protocols. Since router securitymodule 19 is, in various embodiments, running the same routing protocolimplementations as processor 18, the router security module can verifythe route information, thereby allowing router security module 19, andnetwork 10 generally, to detect when a node 12 is acting contrary to theinterests of users of network 10 either through error or maliciousactivity.

In certain embodiments, router security module 19 is configured toremove routing algorithms from processor 18 to protect network 10 froman unauthorized access of information on network 10 or an attempt tocompromise or otherwise remove a particular node 12 or nodes 12 fromnetwork 10 without proper authorization, also known in the art asexfiltration. Exfiltration may occur when node 12 is compromised and aroute database and/or other routing algorithms of nodes 12 of network 10is used by an attacker to create a network map of network 10 orotherwise obtain information as to the content and routing of network10. If the routing algorithms included in processor 18 are accessed,modified and reinserted into a processor 18 of network 10, in anexemplary embodiment with one node 12 removed from the routingalgorithms, the removed node 12 may be ignored by some or all of therest of network 10, effectively allowing an attacker to remove nodes 12from network 10. In an embodiment, router security module 19 isconfigured to maintain secure routing algorithms independent ofprocessor 18. In the event of an exfiltration attack, router securitymodule 19 may restore proper routing algorithms to processor 18.

A compromised node 12 may permit falsification of routing informationexchanged between nodes 12 so as to disrupt routing services of network10 and permit exfiltration of network information. Commercial-gradenodes 12, such as conventional off-the-shelf commercial routers, may beparticularly vulnerable to being compromised through exploits andmalicious software that could harm network routing operations.

In an embodiment, network 10 uses identity-based encryption (IBE)algorithms to authenticate routing or control plane messages. Network 10may also be configured to remove a need for a centralized server forencryption and authentication. Identity-based encryption is based onelliptical curve cryptography and operates similar to public keycryptography, as is well known in the art. In various embodiments, thefunctional difference is that identity-based encryption uses an entity'sidentification for its public key. In an exemplary embodiment, thepublic key of an individual node 12 is that individual node's 12 IPaddress. If an origination node 12 sends a message to another node, adestination node 12, origination node 12 could use identity-basedencryption to encrypt the message using the destination node's 12 IPaddress. When the destination node 12 receives the message, destinationnode 12 may use a private key of destination node 12 to decrypt themessage. Likewise, origination node 12 may sign the message using aprivate key and destination node 12 may then use the source IP addressof the packet to verify the message. Using identity-based encryption mayreduce or obviate a need for a centralized key server to verify a routeror the need to transmit long certificates, as is well know andconventionally used in the art.

As an intermediate node 12 receives routing messages from an originationnode 12, intermediate node 12 updates a routing database and thensecurely sends the message to destination nodes 12. In variousembodiments, intermediate nodes 12 authenticate the message before addthe routing information to intermediate nodes 12 databases and sendingthe message to the destination node 12. In various embodiments, therouting database is distributed throughout network 10. In suchembodiments, since nodes 12 of network 10 incorporate the same routingdatabase and are also running Open Shortest Path First (OSPF) and/orBorder Gateway Protocol (BGP), nodes 12 of network 10 may confirm whatrouting messages a transmitting node 12 should or would be expected tosend if the transmitting node is functioning properly. If the routingmessages sent by transmitting node 12 are contrary to expectation thentransmitting node 12 (or its protocol implementations) may not beoperating correctly. The transmitting node 12 may be quarantined fromthe rest of network 10 and administrators notified.

As described above, Open Shortest Path First (OSPF) and Border GatewayProtocol (BGP) is executed in a distributed manner, i.e., each processor18 of each node 12 performing routing and network management functions.In an alternative or supplemental embodiment, Open Shortest Path First(OSPF) and Border Gateway Protocol (BGP) implementations are switchedoff in multiple processors 18 of network 10 or are not included at allon in several processors 18. In such an embodiment all route protocolfunctions are performed in a single, centralized processor 18 orotherwise on a single node 12 of network 10 which also stores therouting database. As centralized processor 18 receives routing updates,it may update its local router's next hop tables so that network 10 ingeneral routes data correctly. In the event that a node 12 becomescompromised or begins operating incorrectly, centralized processor 18may detect such behavior and prevent bad routing information from beingdistributed to the rest of network 10.

In various embodiments, when two nodes 12 initiate a connection witheach other, network 10 is configured to use identity-based encryption toauthenticate nodes 12 and set-up a shared symmetric key that nodes 12may use for an encrypted tunnel or other suitable communication schemeknown in the art. In an embodiment, a centralized processor 18 ordistributed processors 18 provide such authentication. As such, whilenetwork 10 may utilize an organic key management system without acentralized server, network may, as noted above, utilize a centralizedkey distribution server to initialize nodes' 12 private keys before use.In various embodiments, private keys contain an expiration time thatcauses the private keys to be invalid after the specified time.

In various embodiments, the key distribution server is configured topreload nodes 12 with a list of its private keys that nodes 12 may useover time. In such embodiments, each key in the list is only valid for apredetermined amount of time. The resolution of the key expiration is,in various embodiments, as small as or smaller than one minute or aslarge as valid for an entire duration of network 10. In variousembodiments, the private keys are valid from one to fifteen minutes. Inan exemplary embodiment, if origination node 12 wishes to encrypt amessage so that only destination node 12 can read the message,origination node 12 may use destination node's 12 identity, such asdestination node's 12 IP address and a key expiration time. The privatekey expiration time may be known to origination node 12 since theorigination node 12 may notify destination node what the key expirationtime period is. In various embodiments, every node 12 of network 10 havesynced system clocks, in an embodiment based on the Global PositioningSystem or other generally available timing system, in part for thepurpose of coordinating private key expiration times.

Private keys may be protected utilizing processor 18 if processor 18 istrusted hardware. If processor 18 is not trusted, the private keys canbe stored in a separate partition of an operating system of processor18. Firewalls and memory management techniques can be used to protectthe keys as is well known in the art. In addition, the private keys maybe stored on a partition in a trusted operating system. Further, theprivate keys may be stored within a trusted crypto card as known in theart.

In an embodiment, router security module 19 may be configured to protectuntrusted nodes 12 and network 10 in general from non-conforming nodes12. Router security module 19 may be utilized if a node 12 is runningrouting protocol algorithms. In an embodiment, router security module 19is located in each node 12 configured to run network 10 software onlocal processor 18. Router security module 19 may be configured to checkrouting packets going to and coming from the resident node 12 bychecking to see if the routing packet contains false information.

Router security module 19 may be able to detect false information byitself by running an implementation of Open Shortest Path First (OSPF)and Border Gateway Protocol (BGP). Router security module 19 may alsoincorporate a routing database that is a copy of a routing database kepton processor 18. As nodes send Open Shortest Path First (OSPF) andBorder Gateway Protocol (BGP) messages, router security module 19 maycompare those messages against what router security module 18 thinks atransmitting node 12 should be sending. If router security module 19detects transmitting node 12 is trying to send false information, routersecurity module 19 may quarantine the packet and notify a networkadministrator of the anomaly. In this way, network 10 may be protectedagainst false information.

FIGS. 2-4 illustrate various hardware and software implementations ofsecurity structures of network 10. FIG. 2 is network stack 20 as may beoperated on processor 18 of node 12. Network stack 20 incorporates userlayer 22 and kernel layer 24. Router software 26 is visible to a user onuser layer 22. Transport layer 28 controls routing functionality whilenetwork layer 30 manages network functionality. Organically AssuredRouting System (OARS) device driver 32, as described above in particularwith respect to embodiments of router security module 19 implemented assoftware run on processor 18, manages the flow of packets between routeprotocols and network 10 while maintaining the organic ability ofnetwork 10 to incorporate and drop nodes 12 from network 10 as nodes 12enter or leave an effective range of network 10. OARS device driverexists in both in user layer 22 and kernel layer 24. Link layer 34manages transmission of packets over network 10. In embodiments where anetwork administrator has access to nodes' 12 hardware and operatingsystem but not routing software, OARS device driver 32 implementationcan be utilized. In an exemplary embodiment, OARS device driver 32 isproprietary routing software running on a Linux operating system, whereOARS device driver 32 is installed in network stack 20 of the Linuxkernel. In various embodiments, packets travelling between routersoftware 26 and network 10 can be intercepted by OARS device driver 32.

FIG. 3 is an illustration of an application provider interfaceapplication 40 to interface with conventional router software 42 as runon processor 18. If access to node's 12 router software 42 is available,OARS software application provider interface (API) 44 may be utilized tobridge router software 42 to OARS module 46 as operated on a separate,hardware-implemented embodiment of router security module 19. SoftwareAPI 44 may be configured to allow router software 42 to integrate OARSmodule 46 directly into router software 42. FIG. 3 thus stands incontrast to the embodiment of FIG. 2 in that router security module 19functions as part of a separate OARS hardware module 46 mechanically andlogically isolated from general router software 42 of processor 18 inFIG. 3, while FIG. 2 integrates router security module 19 directly intoprocessor 18 by way of OARS device driver 32.

FIG. 4 is an illustration of closed-system software implementation 50for use with untrusted hardware, such as embodiments where processor 18is untrusted. If node 12 is a closed system where access to routerhardware or software 54 is impractical or impossible, OARS externalhardware plug-in 52 is installed on processor 18 or other computingdevice coupled to the router. OARS external hardware plug-in 52 isconfigured to transmit routing commands to router hardware 54 so thatrouter hardware 54 directs routing messages through OARS externalhardware plug-in 52 so that routing message may be properly managed innetwork 10 as described in detail above.

FIG. 5 is a flowchart for providing organically assured network routingin network 10. A first signal is transmitted (500) from a first node 12of network 10. In an embodiment, the identification includes anidentity-based encryption identifier, such as information indicative ofthe identification of the first node 12. In various embodiments, a firstportion of a symmetric key is generated (502) based on a first privatekey and the identification of the first node 12. In certain suchembodiments, a second node 12 receives the first transmission andgenerates the first portion of the symmetric key. The second node 12then transmits (504) a second signal having information indicative ofthe identification of the second node and the first portion of thesecond key. In various embodiments, the first node 12 receive the secondtransmission and generates (506) a second portion of the symmetric keyusing a private key and the information indicative of the identificationof the second node. The first node 12 then transmits (508) a thirdsignal containing the second portion of the symmetric key to the secondnode 12, whereupon the first and second nodes 12 may be configured toconduct secure communications using a tunnel or other communicationschemes known in the art as described above. The process mayperiodically begin anew at (500) in order to refresh the symmetric key.The process may begin again based on an expiration time of the symmetrickey.

While the above methodology may be implemented according to aDiffie-Hellman methodology as is well known in the art, alternative keyexchanges as known in the art or which may be developed in the futuremay be utilized. Furthermore, where processor 18 of one node 12 istrusted and processor 18 of a different node 12 is not trusted,processing functions above may be performed on trusted processor 18.Alternatively, where not-trusted processor 18 may be made trustedthrough the implementation of OARS device driver 32 on processor 18 orOARS module 46 physically coupled to processor 18 as described withrespect to FIGS. 3 and 4, for instance, not-trusted processor 18 may beutilized with trusted processor 18. In this way, nodes 12 may be addedto or subtracted from network 10 organically and without a need toactively manage the membership of network 10 by an administrator.

Thus, various embodiments of the invention are disclosed. One skilled inthe art will appreciate that the present invention can be practiced withembodiments other than those disclosed. The disclosed embodiments arepresented for purposes of illustration and not limitation, and thepresent invention is limited only by the claims that follow.

What is claimed is:
 1. A device implemented method for dynamicallyestablishing encrypted communications between a first node having afirst identification and a first private key and a second node having asecond identification and a second private key, comprising the steps of:transmitting a first signal comprising information indicative of saidfirst identification of said first node; then transmitting, upon receiptof said first signal by said second node, a second signal comprisinginformation indicative of said second identification of said second nodeand a first portion of a symmetric key; then transmitting, upon receiptof said second signal by said first node, a third signal comprising asecond portion of said symmetric key.
 2. The method of claim 1 whereinat least one of said second signal and said third signal is encrypted.3. The method of claim 2 wherein said at least one of said second signaland said third signal are encrypted according to at least one of saidfirst portion of said symmetric key and said second portion of secondsymmetric key.
 4. The method of claim 1 wherein said first private keyand said second private key are based, at least in part, on time.
 5. Themethod of claim 1 further comprising the steps of: generating with saidsecond node, after said transmitting said first signal step, said firstportion of said symmetric key based, at least in part, on saidinformation indicative of said first identification of said first nodeand said second private key; and generating with said first node, aftersaid transmitting said second signal step, said second portion of saidsymmetric key based, at least in part, on said information indicative ofsaid second identification of said second node and said first privatekey; and
 6. The method of claim 5 wherein: said first node comprises afirst processor and said second node comprises a second processor;wherein said first processor and said second processor are trustedhardware; and wherein said generating with said second node step issoftware implemented on said second processor and said generating withsaid first node step is software implemented with said second processor.7. The method of claim 6 wherein said first processor and said secondprocessor implement a software scheme having a plurality of softwarelayers, and wherein said generating with said second node step and saidgenerating with said first node steps are software implemented as one ofsaid plurality of software layers.
 8. The method of claim 1 wherein:said first node comprises a first processor and said second nodecomprises a second processor; wherein at least one of said firstprocessor and said second processor is untrusted hardware; and wherein,if said first processor is untrusted, said generating with said firstnode step is performed with a first hardware module coupled to saidfirst node and otherwise said generating with said first node step isperformed with said first processor; and wherein, if said secondprocessor is untrusted, said generating with said second node step isperformed with a second hardware module coupled to said second node andotherwise said generating with said second node step is performed withsaid second processor.
 9. The method of claim 1 wherein each of saidtransmitting steps transmits only one data packet apiece.
 10. The methodof claim 1 wherein at least one of said first identification and saidsecond identification is an internet protocol address of said first nodeand an internet protocol address of said second node, respectively. 11.The method of claim 1 wherein at least said transmitting said firstsignal step is a multicast signal to at least said second node and athird node different than said first node and said second node.
 12. Themethod of claim 1 further comprising the step, upon completion of saidtransmitting said third signal, of returning to said transmitting saidfirst signal step.
 13. The method of claim 12 wherein said step ofreturning to said transmitting said first signal step refreshes saidsymmetric key.
 14. The method of claim 13 wherein said step of returningto said transmitting said first signal step occurs periodically.
 15. Themethod of claim 13 wherein said symmetric key has an expiration time andwherein said returning step occurs after said expiration time.
 16. Themethod of claim 1 wherein said first private key is the same as saidsecond private key.
 17. The method of claim 1 wherein said first privatekey is different than said second private key.
 18. A dynamicallyconfigured encrypted network, comprising: a first node having a firstidentification and a first private key; a second node communicativelycoupled to said first node and having a second identification and asecond private key; wherein said first node is configured to transmit afirst signal comprising information indicative of said firstidentification of said first node; wherein said second node isconfigured to transmit, upon receipt of said first signal by said secondnode, a second signal comprising information indicative of said secondidentification of said second node and a first portion of a symmetrickey; and wherein said first node is configured to transmit, upon receiptof said second signal, a third signal comprising a second portion ofsaid symmetric key.
 19. The network of claim 18 wherein at least one ofsaid second signal and said third signal is encrypted.
 20. The networkof claim 19 wherein said at least one of said second signal and saidthird signal are encrypted according to at least one of said firstportion of said symmetric key and said second portion of secondsymmetric key.
 21. The network of claim 18 wherein said first privatekey and said second private key are based, at least in part, on time.22. The network of claim 18 wherein: said first portion of saidsymmetric key being based, at least in part, on said informationindicative of said first identification of said first node and saidsecond private key; and said second portion of said symmetric key beingbased, at least in part, on said information indicative of said secondidentification of said second node and said first private key; and 23.The network of claim 22 wherein: said first node comprises a firstprocessor and said second node comprises a second processor; whereinsaid first processor and said second processor are trusted hardware; andsaid first portion of said symmetric key being software generated onsaid trusted hardware of said second processor.
 24. The network of claim23 wherein said first processor and said second processor implement asoftware scheme having a plurality of software layers and wherein saidfirst portion of said symmetric key and said second portion of saidsymmetric key are generated one of said plurality of software layers.25. The network of claim 22 wherein: said first node comprises a firstprocessor and said second node comprises a second processor; wherein atleast one of said first processor and said second processor is untrustedhardware; and wherein, if said first processor is untrusted, said firstportion of said symmetric key is generated with a first trusted hardwaremodule coupled to said first node and otherwise said first portion ofsaid symmetric key is generated with said first processor; and wherein,if said second processor is untrusted, said second portion of saidsymmetric key is generated with a second trusted hardware module coupledto said first node and otherwise said second portion of said symmetrickey is generated with said second processor.
 26. The network of claim 18wherein said first node is configured to transmit said signal comprisinginformation indicative of said first identification of said first nodein a single data packet and wherein said second node is configured totransmit said second signal comprising information indicative of saidsecond identification of said second node in a single data packet. 27.The network of claim 18 wherein at least one of said firstidentification and said second identification is an Internet protocoladdress of said first node and an internet protocol address of saidsecond node, respectively.
 28. The network of claim 18 wherein saidfirst node is configured to transmit said signal comprising informationindicative of said first identification of said first node as amulticast signal to at least said second and a third node different thansaid first node and said second node.
 29. The network of claim 18wherein said first node is configured, upon completion of transmissionof said third signal, to again transmit said first signal comprisinginformation indicative of said first identification of said first node.30. The network of claim 29 wherein said symmetric key is refreshed. 31.The network of claim 30 wherein said symmetric key is refreshedperiodically.
 32. The network of claim 30 wherein said symmetric key hasan expiration time and wherein said symmetric key is refreshed aftersaid expiration time.
 33. The network of claim 18 wherein said firstprivate key is the same as said second private key.
 34. The network ofclaim 18 wherein said first private key is different than said secondprivate key.
 35. A node configured to dynamically establish encryptedcommunication with a second node having a second identification and asecond private key, comprising: a first identification different fromsaid second identification; a first private key different from saidsecond private key; and a transceiver, configured to: transmit a firstsignal comprising information indicative of said first identification ofsaid first node; receive a second signal, transmitted by said secondnode upon receipt of said first signal, comprising informationindicative of said second identification of said second node and a firstportion of a symmetric key; and transmit, upon receipt of said secondsignal, a third signal comprising a second portion of said symmetrickey.
 36. The node of claim 35 wherein at least one of said second signaland said third signal is encrypted.
 37. The node of claim 36 whereinsaid at least one of said second signal and said third signal areencrypted according to at least one of said first portion of saidsymmetric key and said second portion of second symmetric key.
 38. Thenode of claim 35 wherein said first private key and said second privatekey are based, at least in part, on time.
 39. The node of claim 35wherein: said first portion of said symmetric key being based, at leastin part, on said information indicative of said first identification ofsaid first node and said second private key; and said second portion ofsaid symmetric key being based, at least in part, on said informationindicative of said second identification of said second node and saidfirst private key; and
 40. The node of claim 39 wherein: said first nodeis trusted hardware having a first processor; and said first portion ofsaid symmetric key being software generated on said trusted hardware ofsaid second processor.
 41. The node of claim 40 wherein said firstprocessor implements a software scheme having a plurality of softwarelayers and wherein said first portion of said symmetric key is generatedin one of said plurality of software layers.
 42. The node of claim 39wherein said first node is untrusted hardware having a first processor;and said first portion of said symmetric key is generated with a trustedhardware module coupled to said first node.
 43. The node of claim 35wherein said first node is configured to transmit said signal comprisinginformation indicative of said first identification of said first nodein a single data packet.
 44. The node of claim 35 wherein at least oneof said first identification and said second identification is aninternet protocol address of said first node and an internet protocoladdress of said second node, respectively.
 45. The node of claim 35wherein said first node is configured to transmit said signal comprisinginformation indicative of said first identification of said first nodeas a multicast signal to at least said second and a third node differentthan said first node and said second node.
 46. The node of claim 35wherein said first node is configured, upon completion of transmissionof said third signal, to again transmit said first signal comprisinginformation indicative of said first identification of said first node.47. The node of claim 46 wherein said symmetric key is refreshed. 48.The node of claim 47 wherein said symmetric key is refreshedperiodically.
 49. The node of claim 47 wherein said symmetric key has anexpiration time and wherein said symmetric key is refreshed after saidexpiration time.
 50. The node of claim 35 wherein said first private keyis the same as said second private key.
 51. The node of claim 35 whereinsaid first private key is different than said second private key.